WARNING:
JavaScript is turned OFF. None of the links on this concept map will
work until it is reactivated.
If you need help turning JavaScript On, click here.
此概念图以 IHMC CmapTools 创建, 内含信息有关于: 第三章表達系統內部的結構:「類別圖」(Class Diagram)、「循序圖」(Sequence Diagram)、「溝通圖」(Communication Diagram), 問題與分析 是 只是若從架構師的角度來看,他所關心的是領域模型是 否可以被完整轉換成物件模型,因此,溝通圖對架構師 來說較為直覺;至於從程式設計師的角度來看,循序圖 則比較能夠表達程式的邏輯,因此,通常會要求設計師 使用循序圖來表達。, 問題與分析 是 一般來說,我們在使用案例分析中,把系統應該要滿足 的使用者期望找出來了:而在類別圖中,則是把系統的 架構建構出來。但是,針對每一個特定之使用案例的情 境(Scenario),要如何利用類別圖所規範的物件,來完成 使用案例所交付的任務,就必須要利用循序圖來表達。 循序圖最主要的目的,就是在表達物件與物件之間是如 何溝通與合作的,也因此,我們才會稱循序圖是一個動 態的模型。, 類別圖的基本認識 是 類別圖可以說是整個開發過程中,最重要的一個產物 。透過類別圖,我們可以瞭解設計人員對其所面對之 領域(Domain)的想像(Conceptual Model),進而瞭解設計 人員在設計上的一些重要設計(Interface、Abstract以及 Design Pattern的應用) 的表達與觀點。, 信仁醫院住出院系統的循序圖範例 是 登記出院記錄的使用案例敘述(正常流程) 1. 醫護人員提供【病患出院申請紀錄】 2. 系統儲存【病患出院申請紀錄】 3. 系統提供【病患住院資訊】 4. 收費管理系統提供【住院費用】給系統 5. 系統根據【病床費用計算邏輯】計算病床費用 6. 系統儲存【病患出院資訊】 根據這個使用案例敘述,「登記出院記錄」的循序圖應 如下所示。, 總結 是 在類別圖中,其主要表達的是問題領域的「抽象概 念」,在這個抽象概念中,除了表達該抽象概念的 名稱外,另外需要表達該抽象概念的「屬性」與「 行為」。, 問題與分析 是 那麼,「本質」究竟是什麼?正如同前一節中的情節 描述,「本質」指的就是要想辦法直指想要解決的問 題的「核心」。, 循序圖的基本認識 是 物件與物件之間,必須要透過訊息(Message)來傳遞。 所謂的訊息,其實就是該物件所屬類別的某一個操作 (Operation)。若是該訊息尚未被定義在物件所屬的類 別中,可以使用「//訊息名稱」的方式來說明。兩個 物件間若能夠溝通訊息的話,這代表著在類別圖中, 該兩物件所屬的類別必然有關係(Association、Whole- Part、Generalization或是Dependency)。, 類別圖的基本認識 是 針對醫院的診間系統所設計的類別圖。類別圖中最重 要的元素就是類別(Class)。類別主要是由名稱(Name) 、屬性(Attribute)以及操作(Operation)所組成。屬性主 要是類別的某些重要的特性,這通常是屬於「資料面 」的一些描述:操作則是類別可以運作的一些「行為 」(Behavior)。, 第三章表達系統內部的結構:「類別圖」(Class Diagram)、「循序圖」(Sequence Diagram)、「溝通圖」(Communication Diagram) 資料來源根據『UML團隊開發流程與管理』 包括 系統結構與溝通圖, 第三章表達系統內部的結構:「類別圖」(Class Diagram)、「循序圖」(Sequence Diagram)、「溝通圖」(Communication Diagram) 資料來源根據『UML團隊開發流程與管理』 包括 系統結構與循序圖, 信仁醫院案例背景描述 是 HSDe軟體架構師:我看到了你繪製的循序圖,可是總覺 得似乎有些問題,你是否可以解釋一下這張循序圖跟領 域模型的關係 專案設計人員:沒有問題。依照上次會議的結論,我採 用Jacobson的BCE(Boundary-Control-Entity)的分析類別來進 行設計。因此,我先針對「登記出院記錄」的使用案例 ,建立了一個「控制物件」(ControlObject),並命名為「 登記出院記錄Bpo」。 HSDc軟體架構師:這個我瞭解。我先拿你的設計圖來説 明。 接著,HSDe軟體架構師將循序圖與領域模型放在一起做 比較,並且把有疑慮的部分畫出來跟專案設計人員討論。 HSDc軟體架構師:如同我所標示出來的,在領域模型中 ,「登記出院記錄Bpo」並沒有和「病床」類別有任何的 關係,該關係是透過「住院事件」來連接的,但是在循 序圖中,「:登記住院記錄Bpo」的物件卻和":病床」 物件有訊息傳遞,這似乎不大符合領域模型的設計。 專案設計人員:我看看。嗯,好像真的是這樣耶! HSDe軟體架構師:你可否畫出另外一張物件合作圖 (Interaction Diagram),並且同時表達物件結構與訊息呼叫 ,來確認你的設計並沒有違反領域模型。 專案設計人員:我可以在循序圖當中用説明來代替嗎? 因為我覺得循序圖對於程式設計人員來説,似乎比較直覺 HSDe軟體架構師:我並沒有說要取消循序圖啊!循序圖 仍然是給程式設計人員進行程式設計的藍圖,我要的是一 張可以直覺瞭解的物件模型。 專案設計人員:瞭解了,那我另外畫一張「溝通圖」 (CommunicationDiagram)來表達。 HSDc軟體架構師:太好了。, 類別圖的基本認識 是 類別與類別之間最基本的關係就是關聯(Association)。 關聯表達了兩個類別所規範的物件彼此間的結構性關 係。以圖3-1而言,診斷與醫生類別間有一個關聯,這 就代表著「某一個診斷的事件」,一定會有「某-醫生 」來參與。, 問題與分析 是 軟體人員在面對客戶時,常犯的一個錯誤:用太多的 專有名詞 (而且是自己發明的專有名詞,像Master- Details等UI的呈現說明)跟客戶溝通,而忽略了本質性 的討論。, 總結 是 循序圖及溝通圖的目的都在於說明物件的合作如何 達成系統的目標。系統的目標在進行使用案例分析 時,已被區分為多個的子目標,因此,每一張循序 圖所表達的,都是每一個使用案例是如何透過物件 互動來完成。, 問題與分析 是 ■提供程式設計師(Programmer)寫程式的藍圖 循序圖表達的方式是以時間為縱軸,這也恰巧符合程式 寫作的方式,一樣具備「次序性」(order)。不過在繪製 循序圖時,要先打破一個迷思:循序圖並不需要「務 求精細」,因為它畢竟只是一個「藍圖」,並非是完整 的「施工計畫」。, 系統結構與循序圖 包括 循序圖的基本認識, 信仁醫院案例背景描述 緣由是 HSDe的專案經理特別跟信仁醫院的特助說明, 他們的軟體架構師主要是要瞭解一下信仁醫院 的領域模型(Domain Model),因此希望和信仁醫 院中的領域專家(Domain Expert)來溝通。, 問題與分析 是 舉例來說,我們要表達「醫院內部如何處理住出院」 的問題領域,那我們就需要先把這個問題領域中一 些重要的「元素」(element)先抽象出來。「資料」只 是這些元素的其中一種表現方式,因此,我們可以 把「資料」視作是找尋「概念模型」的參考,並不能 把它當作是「概念模型」本身。, 信仁醫院案例背景描述 緣由是 當HSDe的軟體架構師與信仁醫院的特助訪談過後, HSDe的內部召開了第一次軟體開發會議,參與會議 的成員有HSDe的RA、HSDe的軟體架構師以及該專 案的設計人員。以下是該會議進行的情節。, 系統結構與溝通圖 包括 問題與分析